The processing (e.g., compiling) of source code files (i.e., files which are considered, to those skilled in the art, to be “readable”) into binary or object files which can be interpreted and executed by a computer system is a well known process. Generally, many source code files will be created by application developers which will be compiled using a compiler and a “make” utility. As a result of compiling the source code files and linking the resulting object files, a usable and executable application can be created.
The make utility typically only recompiles those modules which have been modified since the last compilation. A make utility, which often is incorporated into or is provided with a compiler, references a “makefile” which lists the application modules that are part of a project and associated libraries that must be linked with these modules. Additionally, the makefile may also include special directives that enable certain modules to be compiled differently if required.
Generally, a makefile, which is interpreted by a make utility, follows the following structure or recipe:
target: dependency                <command>        
When this structure is interpreted by the make utility, the make utility will execute the “command” whenever the “target” is out of date with respect to the “dependency”. As is known in the art, a makefile may contain multiple recipes. For example, with the following makefile “example.mak”:    all: target1 target2 . . . targetN            target1: dependency1                    <command1>                        target2: dependency2                    <command2>                        . . .        targetN: dependencyN                    <commandN>                        
the make utility will process each of these recipes (1, 2, . . . N) serially (i.e., one after another) starting with the first recipe which corresponds to “target1” and then progressing to “target2” and so on until “targetN” is processed. The instruction “all: target1, target2, . . . targetN” is interpreted by the makefile interpreter to process a chain or series of recipes.
Some makefiles are structured in a slightly different manner due to the use of “macros”. A macro is used to assign one or more commands to an assigned macro name. When the macro name is called, the command(s) in the macro are executed from beginning to end. These makefiles which employ macros may be structured in the following manner:
<macro name>=<command(s)>
target: dependency                <macro name><flags><dependencies>        
With this latter structure, a make utility will, upon identifying the “macro name” string, invoke the “command(s)” using the “flags” and “dependencies” specified.
As will be appreciated, the complexity and size of many recently developed applications continues to increase. It is not unusual for a complex application to include thousands of separate source code files. Consequently, computer systems required in the development environment (and often in the deployment environment) include multiple processors to handle the increased compilation loads. However, many makefile utilities, created for single processor systems, are unable to effectively harness the power of multiprocessor systems. Consequently, despite having processing power to spare, many conventional makefile utilities executing on a multiprocessor system compile modules serially (i.e., one after another) despite the opportunity to safely compile many modules in parallel (i.e., compile in parallel those modules which are independent of other modules).
Attempts have been made to address this oversight. Notably, some make utilities are available from the GNU organization (www.gnu.org) and from Sun Microsystems that incorporate extensions to allow parallel compilation. However, these solutions tie the makefiles to the particular make utility and, often, a particular platform (a combination of processing architecture and operating system) and/or shell interpreter. As a result, these solutions are not easily adaptable to multiple platforms and often limit developers to a particular make utility and/or shell interpreter.
Accordingly, a method, system and related embodiments for parallel compiling which addresses, at least in part, some of these shortcomings is desired.